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Abstract 


This specification presents an optional method to add integrity protection directly to the Network 
Service Header (NSH) used for Service Function Chaining (SFC). Also, this specification allows for 
the encryption of sensitive metadata (MD) that is carried in the NSH. 
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Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 
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1. Introduction 


Many advanced Service Functions (SFs) are enabled for the delivery of value-added services. 
Typically, SFs are used to meet various service objectives such as IP address sharing, avoiding 
covert channels, detecting Denial-of-Service (DoS) attacks and protecting network 
infrastructures against them, network slicing, etc. Because of the proliferation of such advanced 
SFs together with complex service deployment constraints that demand more agile service 
delivery procedures, operators need to rationalize their service delivery logic and control its 
complexity while optimizing service activation time cycles. The overall problem space is 
described in [RFC7498]. 


[RFC7665] presents a data plane architecture addressing the problematic aspects of existing 
service deployments, including topological dependence and configuration complexity. It also 
describes an architecture for the specification, creation, and maintenance of Service Function 
Chains (SFCs) within a network, that is, how to define an ordered set of SFs and ordering 
constraints that must be applied to packets/flows selected as a result of traffic classification. 
[RFC8300] specifies the SFC encapsulation: Network Service Header (NSH). 


The NSH data is unauthenticated and unencrypted, forcing a service topology that requires 
security and privacy to use a transport encapsulation that supports such features (Section 8.2 of 
[RFC8300]). 


Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop security between 
two SFC data plane elements (e.g., two Service Function Forwarders (SFFs), SFF to SF) and do not 
provide SF-to-SF security of NSH metadata. For example, if IPsec is used, SFFs or SFs within a 
Service Function Path (SFP) that are not authorized to access the sensitive metadata (e.g., 
privacy-sensitive information) will have access to the metadata. As a reminder, the metadata 
referred to is information that is inserted by Classifiers or intermediate SFs and shared with 
downstream SFs; such information is not visible to the communication endpoints (Section 4.9 of 
[RFC7665]). 


The lack of such capability was reported during the development of [RFC8300] and [RFC8459]. The 
reader may refer to Section 3.2.1 of [NTERNET-THREAT-MODEL] for a discussion on the need for 
more awareness about attacks from within closed domains. 
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This specification fills that gap for SFC (that is, it defines the "NSH Variable Header-Based 
Integrity" option mentioned in Section 8.2.1 of [RFC8300]). Concretely, this document adds 
integrity protection and optional encryption of sensitive metadata directly to the NSH (Section 
4). The integrity protection covers the packet payload and provides replay protection (Section 
7.4). Thus, the NSH does not have to rely upon an underlying transport encapsulation for security. 


This specification introduces new Variable-Length Context Headers to carry fields necessary for 
integrity-protected NSH headers and encrypted Context Headers (Section 5). This specification is 
only applicable to NSH MD Type 0x02 (Section 2.5 of [RFC8300]). MTU considerations are 
discussed in Section 8. This specification is not applicable to NSH MD Type 0x01 (Section 2.4 of 
[RFC8300]) because that MD Type only allows a Fixed-Length Context Header whose size is 16 
bytes; that is not sufficient to accommodate both the metadata and message integrity of the NSH 
data. 


This specification limits access to NSH-supplied information along an SFP to entities that have a 
need to interpret it. 


The mechanism specified in this document does not preclude the use of transport security. Such 
considerations are deployment specific. 


It is out of the scope of this document to specify an NSH-aware control plane solution. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


This document makes use of the terms defined in [RFC7665] and [RFC8300]. The term "transport 
encapsulation" used in this document refers to the outer encapsulation (e.g., Generic Routing 
Encapsulation (GRE), IPsec, and Generic Protocol Extension for Virtual eXtensible Local Area 
Network (VXLAN-GPE)) that is used to carry NSH-encapsulated packets as per Section 4 of 
[RFC8300]. 


The document defines the following terms: 


SFC data plane element: Refers to NSH-aware SF, SFF, the SFC Proxy, or the Classifier as defined 
in the SFC data plane architecture [RFC7665] and further refined in [RFC8300]. 


SFCcontrolelement: Isa logical entity that instructs one or more SFC data plane elements on 
how to process NSH packets within an SFC-enabled domain. 


Key Identifier: Is used to identify keys to authorized entities. See, for example, "kid" usage in 
[RFC7635]. 


Boucadair, et al. Standards Track Page 4 


RFC 9145 Integrity Protection for the NSH December 2021 


NSH data: The NSH is composed of a Base Header, a Service Path Header, and optional Context 
Headers. NSH data refers to all the above headers and the packet or frame on which the NSH is 
imposed to realize an SFP. 


NSH imposer: Refers to an SFC data plane element that is entitled to impose the NSH with the 
Context Headers defined in this document. 


3. Assumptions and Basic Requirements 


Section 2 of [RFC8300] specifies that the NSH data can be spread over three headers: 


Base Header: Provides information about the service header and the payload protocol. 
Service Path Header: Provides path identification and location within an SFP. 


Context Header(s): Carries metadata (i.e., context data) along a service path. 


The NSH allows sharing context information (a.k.a. metadata) with downstream NSH-aware data 
plane elements on a per-SFC/SFP basis. To that aim: 


e The Classifier is instructed by an SFC control element about the set of context information to 
be supplied for a given service function chain. 

e An NSH-aware SF is instructed by an SFC control element about any metadata it needs to 
attach to packets for a given service function chain. This instruction may occur any time 
during the validity lifetime of an SFC/SFP. For a given service function chain, the NSH-aware 
SF is also provided with an order for consuming a set of contexts supplied in a packet. 

e An NSH-aware SF can also be instructed by an SFC control element about the behavior it 
should adopt after consuming context information that was supplied in the NSH. For 
example, the context information can be maintained, updated, or stripped. 

e An SFC Proxy may be instructed by an SFC control element about the behavior it should 
adopt to process the context information that was supplied in the NSH on behalf of an NSH- 
unaware SF (e.g., the context information can be maintained or stripped). The SFC Proxy may 
also be instructed to add some new context information into the NSH on behalf of an NSH- 
unaware SF. 


In reference to Table 1: 


e Classifiers, NSH-aware SFs, and SFC proxies are entitled to update the Context Header(s). 
e Only NSH-aware SFs and SFC proxies are entitled to update the Service Path Header. 


e SFFs are entitled to modify the Base Header (TTL value, for example). Nevertheless, SFFs are 
not supposed to act on the Context Headers or look into the content of the Context Headers 
(Section 4.3 of [RFC7665]). 


Thus, the following requirements: 


e Only Classifiers, NSH-aware SFs, and SFC proxies must be able to encrypt and decrypt a given 
Context Header. 
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e Both encrypted and unencrypted Context Headers may be included in the same NSH. 
e The solution must provide integrity protection for the Service Path Header. 


e The solution must provide optional integrity protection for the Base Header. The implications 
of disabling such checks are discussed in Section 9.1. 


SFC Data Plane Insert, remove, or replace the Update the NSH 
Element NSH 
Insert Remove’ Replace Decrement Update 
Service Index Context 
Header(s) 

Classifier + + + 
Service Function + 
Forwarder (SFF) 
Service Function + + 
(SF) 
Service Function + + + + 
Chaining (SFC) 
Proxy 


Table 1: Summary of NSH Actions 


4. Design Overview 
4.1. Supported Security Services 
This specification provides the functions described in the following subsections. 


4.1.1. Encrypt All or a Subset of Context Headers 


The solution allows encrypting all or a subset of NSH Context Headers by Classifiers, NSH-aware 
SFs, and SFC proxies. 


As depicted in Table 2, SFFs are not involved in data encryption. 


Data Plane Base and Service Path Headers Context Header 
Element Encryption Encryption 
Classifier No Yes 

SFF No No 

NSH-aware SF No Yes 
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Data Plane Base and Service Path Headers Context Header 
Element Encryption Encryption 

SFC Proxy No Yes 
NSH-unaware SF No No 


Table 2: Encryption Function Supported by SFC Data Plane Elements 


Classifier(s), NSH-aware SFs, and SFC proxies are instructed with the set of Context Headers 
(privacy-sensitive metadata, typically) that must be encrypted. Encryption keying material is 
only provided to these SFC data plane elements. 


The control plane may indicate the set of SFC data plane elements that are entitled to supply a 
given Context Header (e.g., in reference to their identifiers as assigned within the SFC-enabled 
domain). It is out of the scope of this document to elaborate on how such instructions are 
provided to the appropriate SFC data plane elements nor to detail the structure used to store the 
instructions. 


The Service Path Header (Section 2 of [RFC8300]) is not encrypted because SFFs use the Service 
Index (SI) in conjunction with the Service Path Identifier (SPI) for determining the next SF in the 
path. 


4.1.2. Integrity Protection 


The solution provides integrity protection for the NSH data. Two levels of assurance (LoAs) are 
supported. 


The first level of assurance is where all NSH data except the Base Header are integrity protected 
(Figure 1). In this case, the NSH imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy. 
SFFs are not provided with authentication material. Further details are discussed in Section 5.1. 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Transport Encapsulation 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Base Header 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Service Path Header 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Context Header (s) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Original Packet 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+ 


I 
M 
$ 


+ 


+ 
+— +—+— ++ 
— E a 


+—+—4+—4+—4+-—+4 


+— +————— + 
1 
v 


------ Scope of integrity-protected data 
Figure 1: First Level of Assurance 


The second level of assurance is where all NSH data, including the Base Header, are integrity 
protected (Figure 2). In this case, the NSH imposer may be a Classifier, an NSH-aware SF, an SFẸF or 
an SFC Proxy. Further details are provided in Section 5.2. 
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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Transport Encapsulation 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Base Header 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Service Path Header 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
l Context Header (s) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Original Packet 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+—+—4+—4+—4-—+4 
— E A Zm 


+ -s 
| 

| 

| 

| 

| 

| 

| 
+-> 
| 
+----Scope of integrity-protected data 
Figure 2: Second Level of Assurance 


The integrity-protection scope is explicitly signaled to NSH-aware SFs, SFFs, and SFC proxies in 
the NSH by means of a dedicated MD Type (Section 5). 


In both levels of assurance, the Context Headers and the packet on which the NSH is imposed are 
subject to integrity protection. 


Table 3 classifies the data plane elements as being involved or not involved in providing integrity 
protection for the NSH. 


Data Plane Element Integrity Protection 


Classifier Yes 
SFF No (first LoA); Yes (second LoA) 
NSH-aware SF Yes 
SFC Proxy Yes 
NSH-unaware SF No 


Table 3: Integrity Protection Supported by SFC Data Plane 
Elements 


4.2. One Secret Key, Two Security Services 


The Authenticated Encryption with Associated Data (AEAD) interface defined in Section 5 of 
[RFC5116] is used to encrypt the Context Headers that carry sensitive metadata and to provide 
integrity protection for the encrypted Context Headers. 


The secondary keys "MAC_KEY" and "ENC_KEY" are generated from the input secret key (K) as 
follows; each of these two keys is an octet string: 
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MAC _KEY: Consists of the initial MAC KEY LEN octets of K, in order. The MAC _KEY is used for 
calculating the message integrity of the NSH data. In other words, the integrity protection 
provided by the cryptographic mechanism is extended to also provide protection for the 
unencrypted Context Headers and the packet on which the NSH is imposed. 


ENC_KEY: Consists of the final ENC_KEY LEN octets of K, in order. The ENC_KEY is used as the 
symmetric encryption key for encrypting the Context Headers. 


The Hashed Message Authentication Code (HMAC) algorithm discussed in [RFC4868] is used to 
protect the integrity of the NSH data. The algorithm for implementing and validating HMACs is 
provided in [RFC2104]. 


The advantage of using both AEAD and HMAC algorithms (instead of just AEAD) is that NSH- 
aware SFs and SFC proxies only need to recompute the message integrity of the NSH data after 
decrementing the SI and do not have to recompute the ciphertext. The other advantage is that 
SFFs do not have access to the ENC_KEY and cannot act on the encrypted Context Headers, and 
(in the case of the second level of assurance) SFFs do have access to the MAC_KEY. Similarly, an 
NSH-aware SF or SFC Proxy not allowed to decrypt the Context Headers will not have access to 
the ENC_KEY. 


The authenticated encryption algorithm or HMAC algorithm to be used by SFC data plane 
elements is typically controlled using the SFC control plane. Mandatory-to-implement 
authenticated encryption and HMAC algorithms are listed in Section 4.3. 


The authenticated encryption process takes four inputs, each of which is an octet string: a secret 
key (ENC_KEY, referred to as "K" in [RFC5116]), a plaintext (P), associated data (A) (which contains 
the data to be authenticated but not encrypted), and a nonce (N). A ciphertext (C) is generated as 
an output as discussed in Section 2.1 of [RFC5116]. 


In order to decrypt and verify, the cipher takes ENC_KEY, N, A, and C as input. The output is either 
the plaintext or an error indicating that the decryption failed as described in Section 2.2 of 
[RFC5116]. 


4.3. Mandatory-to-Implement Authenticated Encryption and HMAC 
Algorithms 


Classifiers, NSH-aware SFs, and SFC proxies MUST implement the AES_128_ GCM [GCM][RFC5116] 
algorithm and SHOULD implement the AES_192_GCM and AES_256_GCM algorithms. 


Classifiers, NSH-aware SFs, and SFC proxies MUST implement the HMAC-SHA-256-128 algorithm 
and SHOULD implement the HMAC-SHA-384-192 and HMAC-SHA-512-256 algorithms. 


SFFs MAY implement the aforementioned cipher suites and HMAC algorithms. 


Note: The use of the AES_128 CBC_LHMAC_SHA_256 algorithm would have avoided the need for 
a second 128-bit authentication tag, but due to the nature of how Cipher Block Chaining (CBC) 
mode operates, AES_128 CBC_HMAC_SHA_256 allows for the malleability of plaintexts. This 
malleability allows for attackers that know the Message Authentication Code (MAC) key but 
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not the encryption key to make changes in the ciphertext and, if parts of the plaintext are 
known, create arbitrary blocks of plaintext. This specification mandates the use of separate 
AEAD and MAC protections to prevent this type of attack. 


4.4. Key Management 


The procedure for the allocation/provisioning of secret keys (K) and the authenticated encryption 
algorithm or MAC_KEY and HMAC algorithm is outside the scope of this specification. As such, this 
specification does not mandate the support of any specific mechanism. 


The document does not assume nor preclude the following: 


e The same keying material is used for all the service functions used within an SFC-enabled 
domain. 


e Distinct keying material is used per SFP by all involved SFC data path elements. 
e Per-tenant keys are used. 


In order to accommodate deployments relying upon keying material per SFC/SFP and also the 
need to update keys after encrypting NSH data fora certain amount of time, this document uses 
key identifiers to unambiguously identify the appropriate keying material and associated 
algorithms for MAC and encryption. This use of in-band identifiers addresses the problem of the 
synchronization of keying material. 


Additional information on manual vs. automated key management and when one should be 
used over the other can be found in [RFC4107]. 


The risk involved in using a group-shared symmetric key increases with the size of the group to 
which it is shared. Additional security issues are discussed in Section 9. 


4.5. New NSH Variable-Length Context Headers 


New NSH Variable-Length Context Headers are defined in Section 5 for NSH data integrity 
protection and, optionally, encryption of Context Headers carrying sensitive metadata. 
Concretely, an NSH imposer includes (1) the key identifier to identify the keying material, (2) the 
timestamp to protect against replay attacks (Section 7.4), and (3) MAC for the target NSH data 
(depending on the integrity-protection scope) calculated using MAC_KEY and, optionally, Context 
Headers encrypted using ENC_KEY. 


An SFC data plane element that needs to check the integrity of the NSH data uses the MAC_KEY 
and HMAC algorithm for the key identifier being carried in the NSH. 


An NSH-aware SF or SFC Proxy that needs to decrypt some Context Headers uses ENC_KEY and 
the decryption algorithm for the key identifier being carried in the NSH. 


Section 7 specifies the detailed procedure. 
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4.6. Encapsulation of NSH within NSH 


As discussed in Section 3 of [RFC8459], an SFC-enabled domain (called an upper-level domain) 
may be decomposed into many sub-domains (called lower-level domains). In order to avoid 
maintaining state to restore upper-level NSH information at the boundaries of lower-level 
domains, two NSH levels are used: an Upper-NSH that is imposed at the boundaries of the upper- 
level domain and a Lower-NSH that is pushed by the Classifier of a lower-level domain in front of 
the original NSH (Figure 3). As such, the Upper-NSH information is carried along the lower-level 
chain without modification. The packet is forwarded in the top-level domain according to the 
Upper-NSH, while it is forwarded according to the Lower-NSH in a lower-level domain. 


+- 
| 
| 
| 
| 
| 
+- 
| 
+----Scope of NSH security protection 
provided by a lower-level domain 


Figure 3: Encapsulation of NSH within NSH 


SFC data plane elements of a lower-level domain include the Upper-NSH when computing the 
MAC. 


Keying material used at the upper-level domain SHOULD NOT be the same as the one used by a 
lower-level domain. 


5. New NSH Variable-Length Context Headers 


This section specifies the format of new Variable-Length Context Headers that are used for NSH 
integrity protection and, optionally, Context Header encryption. 


In particular, this section defines two "MAC and Encrypted Metadata" Context Headers, each 
having specific deployment constraints. Unlike Section 5.1, the level of assurance provided in 
Section 5.2 requires sharing MAC_KEY with SFFs. Both Context Headers have the same format as 
shown in Figure 4. 
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Q 1 2 3 
2) 2s AB G7} Oe) a we) A) 7/ GO) 4] ei 456782 90l 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Metadata Class | Type IU] Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Key Id Len | Key Identifier (Variable) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Timestamp (8 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Nonce Length | Nonce (Variable) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Message Authentication Code and optional Encrypted 
Context Headers (Variable) 


+—??—+— +? +—4+—4 
+—??— +? +? tl tot 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 4: MAC and Encrypted Metadata Context Header 


The "MAC and Encrypted Metadata" Context Headers are padded out to a multiple of 4 bytes as 
per Section 2.2 of [RFC8300]. The "MAC and Encrypted Metadata" Context Header, if included, 
MUST always be the last Context Header. 


5.1. MAC#1 Context Header 


The MAC#1 Context Header is a Variable-Length Context Header that carries MAC for the Service 
Path Header, Context Headers, and the inner packet on which NSH is imposed, calculated using 
MAC_KEY and, optionally, Context Headers encrypted using ENC_KEY. The scope of the integrity 
protection provided by this Context Header is depicted in Figure 5. 


This MAC scheme does not require sharing MAC_KEY with SFFs. It does not require recomputing 
the MAC by each SFF because of TTL processing. Section 9.1 discusses the possible threat 
associated with this level of assurance. 
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Q 1 2 3 
21242845 6 7 7 1 Ae 4b Oy to Gee ae oy eh Ol 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Ver|O|U| Ine | Length |U|U|U|U|MD Type] Next Protocol 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Service Path Identifier | Service Index 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
~ Variable-Length Unencrypted Context Headers (opt.) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Metadata Class | Type IU] Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Key Id Len | Key Identifier (Variable) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Timestamp (8 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Nonce Length | Nonce (Variable) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Encrypted Context Headers (opt.) 
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Message Authentication Code 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+ 
A 
I 
I 
+ 


> -+-+-+-+-+-+-+- 


l? +— +? +— H 


-+-+-+-+-+-+-+- 


Inner Packet on which NSH is imposed 


+—??— +H? +? +? +? +? +4—+l+— 


AN 
I 
I 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


I 
I 
I 
I 
+ 


+ 

| 
+ 
| 
| 
| 
| 
| 
| 
| | 
| Integrity-Protection Scope 
+ 


----Encrypted Data 
Figure 5: Scope of MAC#1 


In reference to Figure 4, the description of the fields is as follows: 


Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]). 
Type: 0x02 (see Section 10). 
U: Unassigned bit (Section 2.5.1 of [RFC8300]). 


Length: Indicates the length of the variable-length metadata in bytes. Padding 
considerations are discussed in Section 2.5.1 of [RFC8300]. 


Key Id Len: Variable. Carries the length of the key identifier in octets. 


Key Identifier: Carries a variable-length Key Identifier object used to identify and deliver keys to 
SFC data plane elements. This identifier is helpful for accommodating deployments 
relying upon keying material per SFC/SFP. The key identifier helps to resolve the 
problem of synchronization of keying material. A single key identifier is used to look 
up both the ENC_KEY and the MAC_KEY associated with a key, and the corresponding 
encryption and MAC algorithms used with those keys. 


Timestamp: Refer to Section 6 for more details about the structure of this field. 
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Nonce Length: Carries the length of the Nonce. If the Context Headers are only integrity 
protected, "Nonce Length" is set to zero (that is, no "Nonce" is included). 


Nonce: Carries the Nonce for the authenticated encryption operation (Section 3.1 of 
[RFC5116]). 


Encrypted Context Headers: Carries the optional encrypted Context Headers. 


Message Authentication Code: Covers the entire NSH data, excluding the Base Header. 


5.2. MAC#2 Context Header 


The MAC#2 Context Header is a Variable-Length Context Header that carries the MAC for the 
entire NSH data calculated using MAC_KEY and, optionally, Context Headers encrypted using 
ENC_KEY. The scope of the integrity protection provided by this Context Header is depicted in 


Figure 6. 


2) 1 2 3 

2) st ZG) Gy 7) ) A Gy GP el | ee ee eh) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+<--+ 
|Ver|O|U| ak | Length |U|U|U|U|MD Next Protocol | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 
| Service Path Identifier Servi 
+-+ 
s 


O 
io) 
H 
3 
joe 
io) 
x< 


+ 
| | 
-+- | 
| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ Variable-Length Unencrypted Context Header | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Metadata Class | Type IU] Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
| Key Id Len | Key Identifier (Variable) ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
~ Timestamp (8 bytes) ~ l 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Nonce Length | Nonce (Variable) ~ 
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
J ~ Encrypted Context Headers (opt.) ~ 
+->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ~ Message Authentication Code ~ 
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ~ Inner Packet on which NSH is imposed ~ 
+ 


| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-- | 
Integrity-Protection Scope ----+ 
----Encrypted Data 
Figure 6: Scope of MAC#2 


In reference to Figure 4, the description of the fields is as follows: 


Metadata Class: MUST be set to 0x0 (Section 2.2 of [RFC8300]). 


Type: 0x03 (see Section 10). 
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U: Unassigned bit (Section 2.5.1 of [RFC8300]). 


Length: Indicates the length of the variable-length metadata in bytes. Padding 
considerations are discussed in Section 2.5.1 of [RFC8300]. 


Key Id Len: See Section 5.1. 

Key Identifier: See Section 5.1. 

Timestamp: See Section 6. 

Nonce Length: See Section 5.1. 

Nonce: See Section 5.1. 

Encrypted Context Headers: Carries the optional encrypted Context Headers. 


Message Authentication Code: Covers the entire NSH data. 


6. Timestamp Format 


This section follows the template provided in Section 3 of [RFC8877]. 


The format of the Timestamp field introduced in Section 5 is depicted in Figure 7. 


o 1 2 3 
th ee ee Gl e/a) ah A Sh tay oy 7/ tah 2) 0G) 1] eh yay 7/ te CY) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Seconds 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Fraction 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Figure 7: Timestamp Field Format 


+—+—+ 


Timestamp field format: 
Seconds: Specifies the integer portion of the number of seconds since the epoch. 


+Size: 32 bits 
+ Units: Seconds 
Fraction: Specifies the fractional portion of the number of seconds since the epoch. 


+ Size: 32 bits 


+Units: The unit is 2°32) seconds, which is roughly equal to 233 picoseconds. 


Epoch: 
The epoch is 1970-01-01T00:00 in UTC time. Note that this epoch value is different from the one 
used in Section 6 of [RFC5905] (which will wrap around in 2036). 
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Leap seconds: 
This timestamp format is affected by leap seconds. The timestamp represents the number of 
seconds elapsed since the epoch minus the number of leap seconds. 


Resolution: 
The resolution is 2032) seconds. 


Wraparound: 


232 


This time format wraps around every seconds, which is roughly 136 years. The next 


wraparound will occur in the year 2106. 


Synchronization aspects: 
It is assumed that SFC data plane elements are synchronized to UTC using a synchronization 
mechanism that is outside the scope of this document. In typical deployments, SFC data plane 
elements use NTP [RFC5905] for synchronization. Thus, the timestamp may be derived from 
the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock 
of an NTP server. Since this time format is specified in terms of UTC, it is affected by leap 
seconds (in a manner analogous to the NTP time format, which is similar). Therefore, the value 
of a timestamp during or slightly after a leap second may be temporarily inaccurate. 


7. Processing Rules 


The following subsections describe the processing rules for integrity-protected NSH and, 
optionally, encrypted Context Headers. 


7.1. Generic Behavior 


This document adheres to the recommendations in Section 8.1 of [RFC8300] for handling the 
Context Headers at both ingress and egress SFC boundary nodes (i.e., to strip the entire NSH, 
including Context Headers). 


Failures of a Classifier to inject the Context Headers defined in this document SHOULD be logged 
locally while a notification alarm MAY be sent to an SFC control element. Failures of an NSH- 
aware node to validate the integrity of the NSH data MUST cause that packet to be discarded while 
a notification alarm MAY be sent to an SFC control element. The details of sending notification 
alarms (i.e., the parameters that affect the transmission of the notification alarms depending on 
the information in the Context Header such as frequency, thresholds, and content in the alarm) 
SHOULD be configurable. 


NSH-aware SFs and SFC proxies MAY be instructed to strip some encrypted Context Headers from 
the packet or to pass the data to the next SF in the service function chain after processing the 
content of the Context Headers. If no instruction is provided, the default behavior for 
intermediary NSH-aware nodes is to maintain such Context Headers so that the information can 
be passed to the next NSH-aware hops. NSH-aware SFs and SFC proxies MUST reapply the integrity 
protection if any modification is made to the Context Headers (e.g., strip a Context Header, 
update the content of an existing Context Header, insert a new Context Header). 
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An NSH-aware SF or SFC Proxy that is not allowed to decrypt any Context Headers MUST NOT be 
given access to the ENC_KEY. 


Otherwise, an NSH-aware SF or SFC Proxy that receives encrypted Context Headers, for which it is 
not allowed to consume a specific Context Header it decrypts (but consumes others), MUST keep 
that Context Header unaltered when forwarding the packet upstream. 


Only one instance of a "MAC and Encrypted Metadata" Context Header (Section 5) is allowed in 
an NSH level. If multiple instances of a "MAC and Encrypted Metadata" Context Header are 
included in an NSH level, the SFC data plane element MUST process the first instance and ignore 
subsequent instances and MAY log or increase a counter for this event as per Section 2.5.1 of 
[RFC8300]. If NSH within NSH is used (Section 4.6), distinct LoAs may be used for each NSH level. 


MTU and fragmentation considerations are discussed in Section 8. 


7.2. MAC NSH Data Generation 


After performing any Context Header encryption, the HMAC algorithm discussed in [RFC4868] is 
used to integrity protect the target NSH data. An NSH imposer inserts a "MAC and Encrypted 
Metadata" Context Header for integrity protection (Section 5). 


The NSH imposer sets the MAC field to zero and then computes the message integrity for the 
target NSH data (depending on the integrity-protection scope discussed in Section 5) using the 
MAC_KEY and HMAC algorithm. It inserts the computed digest in the MAC field of the "MAC and 
Encrypted Metadata" Context Header. The length of the MAC is decided by the HMAC algorithm 
adopted for the particular key identifier. 


The Message Authentication Code (T) computation process for the target NSH data with HMAC- 
SHA-256-128() can be illustrated as follows: 


T = HMAC-SHA-256-128(MAC_KEY, target NSH data) 


An entity in the SFP that updates the NSH MUST follow the above behavior to maintain message 
integrity of the NSH for subsequent validations. 


7.3. Encrypted NSH Metadata Generation 


An NSH imposer can encrypt Context Headers carrying sensitive metadata, i.e., encrypted and 
unencrypted metadata may be carried simultaneously in the same NSH packet (Sections 5 and 6). 


In order to prevent pervasive monitoring [RFC7258], it is RECOMMENDED to encrypt all Context 
Headers. All Context Headers carrying privacy-sensitive metadata MUST be encrypted; by doing 
so, privacy-sensitive metadata is not revealed to attackers. Privacy-specific threats are discussed 
in Section 5.2 of [RFC6973]. 


Using the secret key (ENC_KEY) and authenticated encryption algorithm, the NSH imposer 
encrypts the Context Headers (as set, for example, in Section 3) and inserts the resulting payload 
in the "MAC and Encrypted Metadata" Context Header (Section 5). The additional authenticated 
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data input to the AEAD function is a zero-length byte string. The entire Context Header carrying 
sensitive metadata is encrypted (that is, including the MD Class, Type, Length, and associated 
metadata of each Context Header). 


More details about the exact encryption procedure are provided in Section 2.1 of [RFC5116]. In 
this case, the associated data (A) input is zero length for AES Galois/Counter Mode (AES-GCM). 


An authorized entity in the SFP that updates the content of an encrypted Context Header or 
needs to add a new encrypted Context Header MUST also follow the aforementioned behavior. 


7.4. Timestamp for Replay Attack Prevention 


The Timestamp imposed by an initial Classifier is left untouched along an SFP. However, it can be 
updated when reclassification occurs (Section 4.8 of [RFC7665]). The same considerations for 
setting the Timestamp are followed in both initial classification and reclassification (Section 6). 


The received NSH is accepted by an NSH-aware node if the Timestamp (TS) in the NSH is recent 
enough to the reception time of the NSH (TSrt). The following formula is used for this check: 


-Delta < (TSrt - TS) < +Delta 


The Delta interval is a configurable parameter. The default value for the allowed Delta is 2 
seconds. Special care should be taken when setting very low Delta values as this may lead to 
dropping legitimate traffic. If the timestamp is not within the boundaries, then the SFC data plane 
element receiving such packets MUST discard the NSH message. 


Replay attacks within the Delta window may be detected by an NSH-aware node by recording a 
unique value derived from the packet, such as a unique value from the MAC field value. Such an 
NSH-aware node will detect and reject duplicates. If for legitimate service reasons some flows 
have to be duplicated but still share a portion of an SFP with the original flow, legitimate duplicate 
packets will be tagged by NSH-aware nodes involved in that segment as replay packets unless 
sufficient entropy is added to the duplicate packet. Howsuch an entropy is added is 
implementation specific. 


Note: Within the timestamp Delta window, defining a sequence number to protect against 
replay attacks may be considered. In such a mode, NSH-aware nodes must discard packets 
with duplicate sequence numbers within the timestamp Delta window. However, in 
deployments with several instances of the same SF (e.g., cluster or load-balanced SFs), a 
mechanism to coordinate among those instances to discard duplicate sequence numbers is 
required. Because the coordination mechanism to comply with this requirement is service 
specific, this document does not include this protection. 


All SFC data plane elements must be synchronized among themselves. These elements may be 
synchronized to a global reference time. 
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7.5. NSH Data Validation 


When an SFC data plane element that conforms to this specification needs to check the validity 
of the NSH data, it MUST ensure that a "MAC and Encrypted Metadata" Context Header is included 
in a received NSH packet. The imposer MUST silently discard the packet and MUST log an error at 
least once per the SPI if at least one of the following is observed: 


e the "MAC and Encrypted Metadata" Context Header is missing, 
e the enclosed key identifier is unknown or invalid (e.g., the corresponding key expired), or 
e the timestamp is invalid (Section 7.4). 


If the timestamp check is successfully passed, the SFC data plane element proceeds with NSH data 
integrity validation. After storing the value of the MAC field in the "MAC and Encrypted Metadata" 
Context Header, the SFC data plane element fills the MAC field with zeros. Then, the SFC data 
plane element generates the message integrity for the target NSH data (depending on the 
integrity-protection scope discussed in Section 5) using the MAC_KEY and HMAC algorithm. If the 
value of the newly generated digest is identical to the stored one, the SFC data plane element is 
certain that the NSH data has not been tampered with and validation is therefore successful. 
Otherwise, the NSH packet MUST be discarded. The comparison of the computed HMAC value to 
the stored value MUST be done in a constant-time manner to thwart timing attacks. 


7.6. Decryption of NSH Metadata 


If entitled to consume a supplied encrypted Context Header, an NSH-aware SF or SFC Proxy 
decrypts metadata using (K) anda decryption algorithm for the key identifier in the NSH. 


The authenticated encryption algorithm has only a single output, either a plaintext or a special 
symbol (FAIL) that indicates that the inputs are not authentic (Section 2.2 of [RFC5116]). 


8. MTU Considerations 


The SFC architecture prescribes that additional information be added to packets to: 


e Identify SFPs: this is typically the NSH Base Header and Service Path Header. 
e Carry metadata such as that defined in Section 5. 
Steer the traffic along the SFPs: This is realized by means of transport encapsulation. 


This added information increases the size of the packet to be carried along an SFP. 


Aligned with Section 5 of [RFC8300], it is RECOMMENDED that network operators increase the 
underlying MTU so that NSH traffic is forwarded within an SFC-enabled domain without 
fragmentation. The available underlying MTU should be taken into account by network 
operators when providing SFs with the required Context Headers to be injected per SFP and the 
size of the data to be carried in these Context Headers. 
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If the underlying MTU cannot be increased to accommodate the NSH overhead, network 
operators may rely upon a transport encapsulation protocol with the required fragmentation 
handling. The impact of activating such features on SFFs should be carefully assessed by network 
operators (Section 5.6 of [RFC7665]). 


When dealing with MTU issues, network operators should consider the limitations of various 
tunnel mechanisms such as those discussed in [[INTERNET-IP-TUNNELS]. 


9. Security Considerations 


Data plane SFC-related security considerations, including privacy, are discussed in Section 6 of 
[RFC7665] and Section 8 of [RFC8300]. In particular, Section 8.2.2 of [RFC8300] states that attached 
metadata (i.e., Context Headers) should be limited to that which is necessary for correct 
operation of the SFP. Also, that section indicates that [RFC8165] discusses metadata 
considerations that operators can take into account when using NSH. 


The guidelines for cryptographic key management are discussed in [RFC4107]. The group key 
management protocol-related security considerations discussed in Section 8 of [RFC4046] need to 
be taken into consideration. 


The interaction between the SFC data plane elements anda key management system MUST NOT 
be transmitted unencrypted since this would completely destroy the security benefits of the 
integrity-protection solution defined in this document. 


The secret key (K) must have an expiration time assigned as the latest point in time before which 
the key may be used for integrity protection of NSH data and encryption of Context Headers. 
Prior to the expiration of the secret key, all participating NSH-aware nodes SHOULD have the 
control plane distribute a new key identifier and associated keying material so that when the 
secret key is expired, those nodes are prepared with the new secret key. This allows the NSH 
imposer to switch to the new key identifier as soon as necessary. It is RECOMMENDED that the next 
key identifier and associated keying material be distributed by the control plane well prior to the 
secret key expiration time. Additional guidance for users of AEAD functions about rekeying can 
be found in [AEAD-LIMITS]. 


The security and integrity of the key-distribution mechanism is vital to the security of the SFC 
system as a whole. 


NSH data is exposed to several threats: 


e An on-path attacker modifying the NSH data. 

e An attacker spoofing the NSH data. 

e An attacker capturing and replaying the NSH data. 

e Data carried in Context Headers revealing privacy-sensitive information to attackers. 


e An attacker replacing the packet on which the NSH is imposed with a modified or bogus 
packet. 
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In an SFC-enabled domain where the above attacks are possible, (1) NSH data MUST be integrity 
protected and replay protected, and (2) privacy-sensitive NSH metadata MUST be encrypted for 
confidentiality preservation purposes. The Base and Service Path Headers are not encrypted. 


MACs with two levels of assurance are defined in Section 5. Considerations specific to each level 
of assurance are discussed in Sections 9.1 and 9.2. 


The attacks discussed in [ARCH-SFC-THREATS] are handled based on the solution specified in this 
document, with the exception of attacks dropping packets. Such attacks can be detected by 
relying upon statistical analysis; such analysis is out of the scope of this document. Also, if SFFs 
are not involved in the integrity checks, a misbehaving SFF that decrements SI while this should 
be done by an SF (SF bypass attack) will be detected by an upstream SF because the integrity 
check will fail. 


Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control 
Element. These events SHOULD be rate limited. 


The solution specified in this document does not provide data origin authentication. 


In order to detect compromised nodes, it is assumed that appropriate mechanisms to monitor 
and audit an SFC-enabled domain to detect misbehavior and to deter misuse are in place. 
Compromised nodes can thus be withdrawn from active service function chains using 
appropriate control plane mechanisms. 


9.1. MAC#1 


An active attacker can potentially modify the Base Header (e.g., decrement the TTL so the next 
SFF in the SFP discards the NSH packet). An active attacker can typically also drop NSH packets. 
As such, this attack is not considered an attack against the security mechanism specified in the 
document. 


It is expected that specific devices in the SFC-enabled domain will be configured such that no 
device other than the Classifiers (when reclassification is enabled), NSH-aware SFs, and SFC 
proxies will be able to update the integrity-protected NSH data (Section 7.1), and no device other 
than the NSH-aware SFs and SFC proxies will be able to decrypt and update the Context Headers 
carrying sensitive metadata (Section 7.1). In other words, it is expected that the NSH-aware SFs 
and SFC proxies in the SFC-enabled domain are considered fully trusted to act on the NSH data. 
Only these elements can have access to sensitive NSH metadata and the keying material used to 
integrity protect NSH data and encrypt Context Headers. 


9.2. MAC#2 


SFFs can detect whether an illegitimate node has altered the content of the Base Header. Such 
messages must be discarded with appropriate logs and alarms generated (see Section 7.1). 


Similar to Section 9.1, no device other than the NSH-aware SFs and SFC proxies in the SFC-enabled 
domain should be able to decrypt and update the Context Headers carrying sensitive metadata. 
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9.3. Time Synchronization 


[RFC8633] describes best current practices to be considered in deployments where SFC data plane 
elements use NTP for time-synchronization purposes. 


Also, a mechanism to provide cryptographic security for NTP is specified in [RFC8915]. 


10. IANA Considerations 


IANA has added the following types to the "NSH IETF-Assigned Optional Variable-Length 
Metadata Types" registry (0x0000 IETF Base NSH MD Class) at <https://www.iana.org/ 
assignments/nsh>. 


Value Description Reference 
0x02 MAC and Encrypted Metadata #1 RFC9145 


0x03 MAC and Encrypted Metadata #2 RFC9145 


Table 4: Additions to the NSH IETF-Assigned Optional 
Variable-Length Metadata Types Registry 
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